Content-based networks are described in A. Carzaniga, M. J. Rutherford, A. L. Wolf, A routing scheme for content-based networking, Department of Computer Science, University of Colorado, June 2003.
U.S. patent application Ser. No. 11/224,045, the contents of which are herein incorporated by reference, describes a methods and apparatus for highly scalable subscription matching for a content network.
FIG. 1 illustrates an exemplary content-routed network 1. The exemplary content-routed network 1 is composed of a plurality of content-routers 2, 3, 4 and 5, a plurality of publishers 6, 7 and 13, and a plurality of subscribers 8, 9, 10, 11, 12, 14, 15 and 16.
A publisher is a computer or device that can insert content into the network. Another name commonly used in the literature is an event source or a producer. A publisher connects to a content router over a link, using a certain suite of communication protocols. For example, link 17 connects publisher 7 to content router 2. Content takes the form of a set of documents which embodies some information to be shared among participants of a content networks. A typical suite of communication protocols used by publishers to send documents is to encapsulate them within an HTTP header and send them through a TCP/IP connection to a content router, although many other protocols may be utilized.
A subscriber is a computer or device that has expressed interest in some specific content. Another name commonly used in the literature is event displayers or consumers. A subscriber connects to a content router over a link, using similar communication protocols as the publishers. For example, link 22 connects subscriber 14 to content router 4. FIG. 1 also illustrates an example of content from publisher 7 being injected into the content routed network 1. Publisher 7 sends a document 25 to content router 2. Content router 2 receives the document, and matches the contents of the document against its forwarding table. The forwarding table is comprised of a series of expressions that indicates matching conditions against the contents of received documents. For example, for documents formatted as Extensible Markup Language (XML) (refer to Extensible Markup Language (XML) 1.0 (Third Edition)”, W3C Recommendation 4 Feb. 2004, W3C (World Wide Web Consortium)) a suitable subscription syntax is XML Path Language (XPath) (refer to reference “XML Path Language (XPath) Version 1.0”, W3C Recommendation 16 Nov. 1999, W3C (Word Wide Web Consortium)).
In the field of content networks, XML is establishing itself as the language of choice for exchanging documents. Transferring documents in XML does not guarantee the interoperability between the participants of a content network. Sometime the network's participants do not share a common format or schema as is known in the art, for the documents they wish to exchange. It then becomes necessary to transform a document before delivering it to subscribers. A means for specifying these transformations and applying them becomes a requirement of a content network.
FIG. 1 exemplifies a content network 1 with transformation capability comprising content routers (CR) 2, 3, 4, 5, interconnected by links 18, 21, 23 and 24. In this case the network 1 provides the usual content routing function but furthermore it also provides the document transformation capability. The network contains a set of subscriptions which will result in the forwarding of document 25 to subscribers 9, 10, 12 and 14. Subscriber 9 shares the same document format as publisher 7; hence the network will deliver to it an unmodified copy 26 of document 25. Subscriber 10, connected to content router 3 by link 19, and 12 expect the content of publisher 7 to be forwarded to it but for them to make use of the document's content, they require a conversion to a different format, specified by transformation 32. Content router 3 is aware of the required transformation and applies it to the input document 27 producing documents 28 and 29, which then get sent to subscriber 10 and 12 respectively. Similarly, content router 4 is aware of transformations 33 and 34. Subscriber 14 requires two copies of document 25: one copy to be converted as per transformation 33 and another one as per transformation 34. After the transformations have been applied, documents 31 and 35 are sent to subscriber 14.
As per the previous example, a content network's functionality is extended by also providing a document transformation capability. This is done by extending the entries of the content router's forwarding table to also include a reference to one or many transformations. In the above example the forwarding entries that matched input document 27 also specified that transformation 32 should be applied before issuing the document to subscribers 10 and 12. A way of specifying transformations on XML documents is by mean of XSLT stylesheets (refer to reference “XSL Transfomations (XSLT) Version 1.0”, W3C Recommendation 16 Nov. 1999, W3C (Wold Wide Wed Consortium)).
An XSLT processor is a device which takes as input XML documents and XSLT transformations and applies the said transformations to the said input documents. There are many prior art implementations of XSLT processors. Some well known ones include SAXON and Xalan, both public domain XSLT processors. Most internet web browsers also include an XSLT processor. Another prior art XSLT processor example is described in Kuznetsov (U.S. Pat. No. 6,772,413). Kuznetsov provides a method and apparatus of computing what a given transform should be based on the description of the documents' input format and output format. The transformations are computed on the fly as new input format and output format pairs are identified. The result of the computation is machine executable code targeted for a general purpose CPU, the execution of which will transform an input document in a given format to an output document in a different format.
All prior art XSLT processor examples share a common characteristic in that they do not scale very well in terms of speed. For a content router to be able to provide a document transformation capability, it needs to be able to transform document at a speed similar to its forwarding capability. For a commercially available content router like Solace Systems' VRS/32 Value-Added Services System, this would mean a transformation capacity in the order of giga bits per second. None of the prior art architectures scale to such speed and a better approach is clearly required.